Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce fill and fill! on Power manifolds. #190

Merged
merged 11 commits into from
May 19, 2024
Merged

Conversation

kellertuer
Copy link
Member

This introduces fill(M,p) to generate P = (p,...,p) on the power manifold. as well as an in-place fill!(M, P, p),
which I might find helpful in Manopt.jl soon.

We could discuss

  • currently this always creates copies it seems, file fill is documented to generate every entry with the same p
  • the current form generates a few ambiguities, but it follows our idea to have M first; one could argue that M is the size argument here and should therefore be the second argument for that reason (would remove the ambiguities as well).

@kellertuer kellertuer added the Ready-for-Review A label for pull requests that are feature-ready label May 15, 2024
Copy link

codecov bot commented May 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.90%. Comparing base (e760dc5) to head (0ca3cbd).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #190      +/-   ##
==========================================
- Coverage   99.96%   99.90%   -0.07%     
==========================================
  Files          30       30              
  Lines        3241     3257      +16     
==========================================
+ Hits         3240     3254      +14     
- Misses          1        3       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mateuszbaran
Copy link
Member

I think using repeat rather than fill would be more appropriate here.

  • the current form generates a few ambiguities, but it follows our idea to have M first; one could argue that M is the size argument here and should therefore be the second argument for that reason (would remove the ambiguities as well).

If we add methods to generic fill or repeat, we should follow their convention and put manifold second IMO. Integers are valid points on a manifold. fill(PowerManifold(Circle(), 3), 4) already has an established meaning different from what you propose here.

@kellertuer
Copy link
Member Author

fill(PowerManifold(Circle(), 3), 4) already has an established meaning different from what you propose here.

Oh, I was not aware of that, what is that meaning?

I had fill in mind since I want to fill the power manifold point with the ball p.
But Maybe you are right we should then switch the order, since M here is really something very similar to a size/dimension specification.

@kellertuer
Copy link
Member Author

Ah and for repeat, I feel that might be something that sometimes fits, if one has the ArrayRepresentation in mind, but not in general maybe? So I would prefer fill I think.

@mateuszbaran
Copy link
Member

Oh, I was not aware of that, what is that meaning?

julia> fill(PowerManifold(Circle(), 3), 4)
4-element Vector{PowerManifold{ℝ, Circle{ℝ}, Tuple{Int64}, ArrayPowerRepresentation}}:
 PowerManifold(Circle(ℝ), 3)
 PowerManifold(Circle(ℝ), 3)
 PowerManifold(Circle(ℝ), 3)
 PowerManifold(Circle(ℝ), 3)

🙂

I had fill in mind since I want to fill the power manifold point with the ball p.

You can also thinking about it as repeating point p for every component.

@kellertuer
Copy link
Member Author

Oh, indeed, hehe; I did only think of “definitions of fill within ManifoldsBase.jl”.

We can also use both reapeat and fill, but I fear they actually would do the same basically then?

@mateuszbaran
Copy link
Member

We can also use both reapeat and fill, but I fear they actually would do the same basically then?

I prefer repeat but I'm also OK with fill as long as manifold is not the first argument.

@mateuszbaran
Copy link
Member

And yes, there is no reason to have both fill and repeat.

@kellertuer
Copy link
Member Author

My feeling is that for fill you need a size idea which the power manifold provides intuitively,
while repeat requires a number-of-repetitions, which (at least intuitively for me) the power manifold only a-bit-implicitly provides. So I would prefer fill, also because we can have fill! as well.

@kellertuer
Copy link
Member Author

I prefer repeat but I'm also OK with fill as long as manifold is not the first argument.

I totally agree that here the manifold should be second.

@mateuszbaran
Copy link
Member

My feeling is that for fill you need a size idea which the power manifold provides intuitively,
while repeat requires a number-of-repetitions, which (at least intuitively for me) the power manifold only a-bit-implicitly provides. So I would prefer fill, also because we can have fill! as well.

OK, let's use fill then.

@kellertuer
Copy link
Member Author

The two lines we lost look strange in parts I did not even change. Besides that we now have fill and fill! with the better order of parameters.

@kellertuer kellertuer requested a review from mateuszbaran May 18, 2024 10:55
src/PowerManifold.jl Outdated Show resolved Hide resolved
@mateuszbaran
Copy link
Member

I've added support array power representation here. I wouldn't worry about those two missed lines. I think it looks more or less fine now but I'd like to clear your question from that comment before accepting.

src/PowerManifold.jl Outdated Show resolved Hide resolved
…ifoldsBase.jl into kellertuer/power_fill

# Conflicts:
#	src/PowerManifold.jl
@kellertuer
Copy link
Member Author

The Nested replacing case still needs a test.

@mateuszbaran
Copy link
Member

I've added that test. I'm not sure now if nested non-replacing should perhaps make copies of p?

NEWS.md Outdated Show resolved Hide resolved
src/PowerManifold.jl Outdated Show resolved Hide resolved
@kellertuer
Copy link
Member Author

I've added that test. I'm not sure now if nested non-replacing should perhaps make copies of p?

I think it is good as is, replacing has the copy in its name so it copies, nested does not.

@mateuszbaran
Copy link
Member

Yes, it works fine indeed, though the other way (replacing doesn't make copies but non-replacing makes them).

@kellertuer kellertuer merged commit 45ad6af into master May 19, 2024
14 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready-for-Review A label for pull requests that are feature-ready
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants